Copilot vs Delegate — 同步与异步协作
Agent 的协作有两个区间：
Copilot 区间（同步协作）
人在 loop 里，你和 Agent 实时交互，每一步都参与决策。
- 跑几分钟的任务你可以盯着
- 随时能给出上下文纠偏
- 容错成本很低
Delegate 区间（异步委托）
人离开 loop，Agent 独立决策和执行，做完交回来验收。
- 跑两小时的任务你盯不住，也不应该盯
- 任务定义不清 Agent 就跑偏
- 过程中出了问题没人拦
- 验收时一堆东西堆在一起 review
核心矛盾
Agent 能力在增长，能做的事越来越多，独立工作时间越来越长。
工作时间变长，协作方式自然从 Copilot 滑向 Delegate。 这是不可逆的趋势。
Harness Engineering 解决的问题：怎么构建安全的异步委托机制，让这个转变可控。
两种信号
| 信号类型 | 性质 | Harness 能否接入 |
|---|---|---|
| 客观信号 | 编译器、类型检查、lint、测试、CI、线上日志 | ✅ 工程问题，接上就行 |
| 主观信号 | 方向对不对、命名好不好、方案该不该推翻 | ❌ 知识沉淀外化问题，Harness 接不到不存在的东西 |
主观信号是瓶颈
如何让人或组织自然、甚至无感地进行知识沉淀外化，是 Delegate 区间能不能真正持续扩大的关键。
飞轮效应
异步委托机制越完善 → Agent 异步工作越安全 → 人需要介入的地方越少 → Delegate 区间进一步扩大
Agent 能力增长在推，基础设施完善也在推，两股力同向，Delegate 只会越来越多。
关联
- harness-engineering/overview — Harness Engineering 总览
- harness-engineering/three-scaling-dimensions — 三个 Scalability 维度都在解决 Delegate 区间的问题
- harness-engineering/model-spikiness — Jagged Intelligence：Agent 能力分布的高度不均匀性
Karpathy: 可以外包思考，不能外包理解 (2026-04-30)
来源：Karpathy Sequoia AI Ascent 访谈 2026-04
Karpathy 把 Delegate 区间的人机分工进一步具体化：
Agent 像实习生——执行能力强，但判断力不可靠
Karpathy 举了 MenuGen 的实际问题：
- 用户用 Google 登录，用 Stripe 购买 credits
- Agent 实现购买逻辑时，试图用 Stripe 邮箱去匹配 Google 邮箱来关联资金
- 这在工程上危险：一个人完全可能用不同邮箱登录和付款
- 正确做法是用系统内部稳定的 persistent user ID
- Agent 没有理解身份、支付和资金归属的风险——代码能跑、测试可能过，但系统设计是错的
什么可以外包，什么不能
| 可以外包给 Agent | 人必须自己理解 |
|---|---|
| API 细节（keepdims vs keepdim，dim vs axis） | 底层概念（tensor 是什么，view 和 storage 的关系） |
| 具体代码实现 | 顶层设计、约束条件、判断标准 |
| 记住大量语法 | 系统边界——资金和身份该绑定到什么 ID 上 |
| 生成多种方案 | 判断哪条路线是对的，目标是否值得做 |
核心原则：
细节可以外包，理解不能外包。API 名称可以忘，但概念结构不能丢。
人类必须拥有 Plan，Agent 只负责执行
Karpathy 特别强调，他个人并不喜欢那些"plan mode"——不是说它们没用，而是更本质的问题是：人类必须负责 specification，必须负责 plan。 Agent 是执行主体，系统设计、规范定义与质量约束是不可外包的人的责任。
你得和 Agent 一起把一份非常细的 spec 设计出来，某种程度上它甚至应该接近完整文档，然后让 Agent 去填充实现；你自己负责的是顶层监督和大类结构，而 Agent 负责底层执行。
这与本页的 Copilot/Delegate 框架形成对应：Delegate 区间扩大的前提不是"让 Agent 自己决定做什么"，而是"人把 spec 写清楚后，Agent 安全地独立执行"。Spec 不清晰就进入 Delegate 区间，是 Agent 跑偏的根源。
Agent-first 基础设施：Sensors 和 Actuators
Karpathy 用 sensors 和 actuators 的类比描述 Agent 基础设施的底层结构：
需要把世界拆成更底层的结构——哪些部分是感知世界的 sensors，哪些部分是作用于世界的 actuators。让整个系统从根上变成 agent native：所有流程都优先描述给 agent，而不是描述给人。
这对 Delegate 区间的基础设施要求：
- Sensors：Agent 需要可消费的状态信息（文档不写"去某 URL、点某设置"，而写"哪段可以复制给 Agent"）
- Actuators：Agent 需要可安全调用的动作接口（部署、配置、DNS 应能被 Agent 直接调用，而非模拟人点网页）
- 目标：给 LLM 一句 "Build MenuGen"，它写代码、部署上线、配好依赖，全程无需人工操作菜单
这对 Delegate 区间的意义
Karpathy 的回答补充了本页"主观信号是瓶颈"的论断：主观信号不只是"方向对不对""命名好不好"，还包括 Agent 在系统边界上的错误判断。这些错误代码能跑、测试能过，但系统设计是错的——只有人理解系统时才能发现。
人的新瓶颈：要知道到底在建什么、为什么值得做、怎样指导 Agent。思考步骤可以让模型跑很多遍，但如果人没有理解，就无法判断哪条路线是对的。
Addy Osmani：Delegate 区间的五个生产模式 (2026-05-02)
来源：Addy Osmani — Long-running Agents
Addy Osmani 从 Anthropic / Cursor / Google 三家的实践出发，为 Delegate 区间提供了五个具体操作模式：
"定义工作"悖论
定义工作使其足够清晰到 Agent 能跑一天，比亲手干更难。
这与 Karpathy"人类必须拥有 Plan"（见 #Karpathy: 可以外包思考，不能外包理解 (2026-04-30)）完全一致但更尖锐——不是"应该"把 spec 写清楚，而是"写清楚本身就比干活更难"。这解释了为什么 Delegate 区间扩大得慢：瓶颈不在 Agent 能力，在人类表达能力。
委托审批（delegated approval）
人审批时看到的是完整状态（文件变更、测试结果、决策日志），而非序列化的 JSON。Agent 不"请求批准执行下一步"，而是"执行到自然断点，暂停，请求人确认方向后继续"。
关键区别：审批对象是状态快照而非指令序列。人不需要理解 Agent 做了什么，只需要判断当前状态是否正确。
环境处理（ambient processing）
从"人在 loop 里"进化到"事件驱动，无人监督"：
- Agent 监听 webhook / cron / CI 事件
- 事件触发后自动执行预定义工作流
- 异常时才通知人
这也是一种 Delegate 模式，但触发条件从"人委托"变成了"系统事件"。对 harness 的要求更高——需要可靠的事件路由、认证、失败重试和告警。